paypal/js/frontend.js (2)

421-432: ⚡ Quick win

Async callback in setInterval can cause overlapping executions.

The setInterval callback is async, but setInterval doesn't await its callback. If checkPredicate() takes longer than the interval (50ms), multiple invocations can overlap. While the current predicates are likely fast enough, this could cause unexpected behavior with slower async predicates.

Consider using a recursive setTimeout pattern instead:

♻️ Suggested fix using recursive setTimeout

 		const start = Date.now();
 		return new Promise( resolve => {
-			const timer = setInterval( async () => {
-				if ( await checkPredicate() ) {
-					clearInterval( timer );
-					resolve( true );
-				} else if ( Date.now() - start >= timeout ) {
-					clearInterval( timer );
-					resolve( false );
-				}
-			}, interval );
+			const poll = async () => {
+				if ( await checkPredicate() ) {
+					resolve( true );
+				} else if ( Date.now() - start >= timeout ) {
+					resolve( false );
+				} else {
+					setTimeout( poll, interval );
+				}
+			};
+			setTimeout( poll, interval );
 		} );

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@paypal/js/frontend.js` around lines 421 - 432, The current Promise uses an
async callback inside setInterval which can overlap when checkPredicate() is
slow; replace the setInterval pattern with a recursive setTimeout poll loop:
create an inner async function (e.g., poll) that awaits checkPredicate(),
resolves the Promise when it's true, checks elapsed time against timeout to
resolve false, and otherwise schedules the next invocation with setTimeout(poll,
interval); update the Promise at the start (where start, timeout, interval and
checkPredicate are used) to call poll() instead of using setInterval so
overlapping executions cannot occur.

---

379-396: ⚡ Quick win

Redundant config() call and instance creation.

The async predicate (lines 379-387) successfully creates an instance and calls config() to verify eligibility, but these are discarded. Lines 394-396 then create a new instance and call config() again. This doubles the API calls unnecessarily.

Consider caching directly in the predicate to avoid the redundant call:

♻️ Suggested refactor to avoid double config() call

 		// Wait for the config call to actually succeed, not just the function to exist.
 		// This handles the race condition where the function exists but SDK isn't fully initialized.
+		let tempInstance = null;
+		let tempConfig = null;
 		const configReady = await waitFor( async () => {
 			try {
 				const instance = paypal.Applepay();
 				const config = await instance.config();
-				return config?.isEligible;
+				if ( config?.isEligible ) {
+					tempInstance = instance;
+					tempConfig = config;
+					return true;
+				}
+				return false;
 			} catch ( e ) {
 				return false;
 			}
 		} );

 		if ( ! configReady ) {
 			return false;
 		}

 		// Config succeeded, cache it and return true.
-		applePayInstance = paypal.Applepay();
-		applePayConfig = await applePayInstance.config();
+		applePayInstance = tempInstance;
+		applePayConfig = tempConfig;
 		return true;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@paypal/js/frontend.js` around lines 379 - 396, The predicate passed to
waitFor currently creates an instance and calls paypal.Applepay().config(), but
those results are discarded and later code recreates them, causing duplicate API
calls; modify the predicate used in waitFor so that when it successfully obtains
an instance and a config (i.e., paypal.Applepay() and instance.config()), it
assigns them to the outer-scope variables applePayInstance and applePayConfig
and then returns true, and leave the fallback path to return false on
error—remove the later paypal.Applepay() and config() calls so the cached
applePayInstance/applePayConfig are reused.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes